複数のコンポーネントを具備するシステムの故障モード影響解析の支援

专利摘要:
複数のコンポーネント（402A,402B）を具備するシステムの故障モード影響解析を支援する方法は、システムの、コンポーネント（402）、又はコンポーネントのグループに関連付けられたデータ（404）を取得することを含む。コンポーネント又はグループは、コンポーネントのタイプのデータ（406）又はグループのタイプのデータにそれぞれ関連付けられる。コンポーネントのタイプのデータ（406）又はグループのタイプのデータは、そのタイプの、全てのコンポーネント又はグループに、それぞれ共通する少なくとも１つの故障の特徴に関するデータを含む。システムの故障モード影響解析において使用するために、コンポーネント／グループのデータとコンポーネント／グループのタイプのデータとを記憶及び／又は転送することができる。
公开号:JP2011507125A
申请号:JP2010538913
申请日:2008-11-26
公开日:2011-03-03
发明作者:ベル、ジョン・ブライアン；ボベイ、リチャード・リー
申请人:ビ−エイイ− システムズ パブリック リミテッド カンパニ−ＢＡＥ ＳＹＳＴＥＭＳ ｐｌｃ；
IPC主号:G05B23-02

专利说明:

[0001] 本発明は、複数のコンポーネントを具備するシステムの故障モード影響解析の支援に関する。]
背景技術

[0002] 故障モード影響解析は、障害症状モデル（fault-symptom model）を作成するために使用される技術である。障害症状モデルは、既知の症状に関するデータと、既知の故障に対する既知の症状の関係性とを使用して、システムにおいて最も可能性の高い障害を識別するために使用することができる。従って、症状に関する情報がある場合に、エキスパートシステムの診断アプリケーション(例えば、確率的ベイジアンネットワークに基づくもの)は、このモデルを使用して、可能性の高い原因を識別することができる。障害と関連症状との関係性を定義するモデルの構築には、従来、システムと解析技術との両者についての専門知識が必要であり、反復的な手作業で行なわれた。ある場合には、モデルを作成するために、スプレッドシートのようなデータ表現が使用され得る。これは、ユーザが多くのコピー／ペースト作業を行なうことを必要とし、大量の反復データをもたらす。更に、モデルを更新する場合に、これらの従来の方法によって作成された大量のモデルデータは、完全に適切に更新されないことがある。]
[0003] 本願の実施形態は、上述の問題のうちの少なくとも幾つかに対処することを目的とする。]
[0004] 本発明の１つの態様によると、複数のコンポーネントを具備するシステムの故障モード影響解析を支援する方法であって、
システムの、コンポーネント、又はコンポーネントのグループに関連付けられたデータを取得するステップと、
コンポーネント又はグループを、コンポーネントのタイプのデータ又はグループのタイプのデータにそれぞれ関連付けるステップと、
システムの故障モード影響解析において使用するために、コンポーネント／グループのデータとコンポーネント／グループのタイプのデータとを記憶及び／又は転送するステップと、
を含み、
コンポーネントのタイプのデータ又はグループのタイプのデータは、そのタイプの、全てのコンポーネント又はグループに、それぞれ共通する少なくとも１つの故障の特徴に関するデータを含む、
方法が提供される。]
[0005] システムのコンポーネントに関連付けられたデータを取得するステップは、コンポーネントが前記コンポーネントのタイプのデータに既に関連付けられているかどうかを決定するために、システムのモデルを解析するか、又はシステムのモデルの作成を解析するステップ、を含んでもよく、コンポーネントが前記コンポーネントのタイプのデータにまだ関連付けられていない場合には、コンポーネントに対するコンポーネントのタイプのデータを作成して、コンポーネントに関連付ける。]
[0006] モデル（の作成）を解析するステップは、モデル中のコンポーネントの図形表現（graphical representation）のシェイプを検出するステップと、コンポーネントに関連付けられるコンポーネントのタイプのデータを決定するために、シェイプが基づくマスタ又はテンプレートを決定するステップと、を含み得る。]
[0007] 故障の特徴のデータは、故障のタイプ／名称／モード、システム及び／又は他のコンポーネントに対する故障の影響、故障の症状、故障の症状が故障の発生につながる確率を表わす値、故障が発生する先験的確率、症状が１つの(又は１つのみの)前記故障をもたらす条件付き確率、症状がモデル化された故障をもたらさない確率、から成る１つの組から選択され得る。]
[0008] コンポーネント／グループのタイプのデータは、コンポーネント／グループのデータから独立して記憶され得る。コンポーネント／グループのデータは、特定のコンポーネント／グループの故障の特徴に関するデータ、典型的には、特定のコンポーネント／グループの故障の、他のコンポーネント及び／又は他のグループ及び／又はシステムに対する影響を記載したデータ、を含む又は関連付けることができる。]
[0009] モデル中の前記コンポーネントの各々は、一意の識別子を割り当てられ得る。前記コンポーネントのタイプの各々は、一意の識別子を割り当てられ得る。コンポーネントのデータとコンポーネントのタイプのデータとを記憶及び／又は転送するステップは、コンポーネントの一意の識別子と、コンポーネントに関連付けられたコンポーネントのタイプの一意の識別子との間のリファレンスと共に、コンポーネントのデータを記憶／転送するステップを含み得る。]
[0010] システムのモデルの図形部分（graphical part）は、マイクロソフトビジオ（商標）のモデルであってもよく、前記コンポーネントを表現するシェイプを検出するステップは、ビジオにおける「シェイプ追加」イベントを検出することによって実施することができる。このイベントは、ビジオ（商標）のアドオン（Add-on）として構成されているコードを使用して検出することができる。]
[0011] 本発明の別の態様によると、プログラムコードがロードされたときに、実質的にここに記載されているような複数のコンポーネントを具備するシステムの故障モード影響解析を支援する方法を、コンピュータに実行させる、コンピュータプログラムコード手段を有する、コンピュータ読み出し可能媒体を具備する、コンピュータプログラム製品が提供される。]
[0012] 本発明の別の態様によると、複数のコンポーネントを具備するシステムの故障モード影響解析を支援するように構成された装置であって、
システムのコンポーネントに関連付けられたデータを取得するように構成されたデバイスと、
コンポーネントをコンポーネントのタイプのデータに関連付けるように構成されたデバイスと、
システムの故障モード影響解析において使用するために、コンポーネントとコンポーネントのタイプのデータとを記憶及び／又は転送するデバイスと、
を含み、
コンポーネントのタイプのデータは、そのコンポーネントのタイプの全てのコンポーネントに共通する少なくとも１つの故障の特徴に関するデータを含む、
装置が提供される。]
[0013] システムの少なくとも１つの前記コンポーネントは、故障モード影響解析の結果に基づいて、前記コンポーネント自体を(自動的に)適応させるように構成され得る。]
[0014] 本発明の更に別の態様によると、複数のコンポーネントを具備するシステムであって、実質的にここに記載されているような故障モード影響解析の結果として、適応させられる／適応可能なシステムが提供される。本発明の別の態様によると、実質的にここに記載されているような故障症状モデルを作成する方法が提供される。本発明の別の態様によると、実質的にここに記載されているような方法を使用して生成されたシステムのモデル(又は、システム中のコンポーネントの故障の症状と障害との関係性について記載したシステムのモデル)が提供される。]
[0015] 本発明を上述に記載したが、本発明は、上述又は後述に示された特徴の任意の発明的な組み合わせに及ぶ。本発明の例示的な実施形態は、添付の図面を参照してここに詳しく記載されているが、本発明は、これらの実施形態そのものに制限されないと理解されるべきである。従って、多くの変更とバリエーションとが当業者に明らかになるであろう。１つの実施形態の一部として又は個別に記載された特定の特徴について、他の実施形態又は他の特徴が言及していなくても、１つの実施形態の一部として又は個別に記載された特定の特徴は、他の実施形態の一部又は他の個別に記載された特徴と組み合わせることができると考えられる。従って、本発明は、まだ記載されないこのような特定の組み合わせに及ぶ。]
[0016] 本発明は、様々なやり方で実施され得る。ここで、添付の図面を参照して、その実施形態を例示的に記載する。]
図面の簡単な説明

[0017] 例示的なシステム中のコンポーネント間の関係性を示す模式図である。
障害／症状モデルを生成して、障害／症状モデルに基づいて故障モード影響解析を行なうように構成されたコンピューティングデバイスを示す模式図である。
実施形態によって使用される、コンポーネントのデータとコンポーネントのタイプのデータとの模式図である。
障害／症状モデルを作成するために使用されるアプリケーションによって生成される例示的なスクリーンディスプレイの図である。
新たなコンポーネントがモデルに追加される場合に、実施形態によって行なわれるステップを示すフローチャートである。]
実施例

[0018] ここで、一般に故障／症状モデルの作成に関する段階の概要を与える。第１に、対象システムの記述を作成する。システムのコンポーネントのモデルとコンポーネント間の関係性とを描くために、コンピュータソフトウェアを使用して、例えばマイクロソフトビジオ(Microsoft Visio（商標））のようなツールを使用して、記述を作成する段階を、他の段階と同様に、少なくとも部分的に自動化することができる。第２の段階は、システムのコンポーネントの状態及び故障モードを識別することに関し得る。例えば、ポンプトレイ装置において、コンポーネントはタンクを含み、そのバルブに関連付けることができる故障状態は、「漏洩」である。故障モードの識別は、少なくとも1人の専門家の知識に基づき得る。次に、各故障モードに関連付けられる症状を記載した情報を記憶しているテーブル(又は、任意の他の適切なデータ構造)を作成する。一般に、これも、モデル化されるシステムを実際に構築した経験から得られる専門知識に基づく。第４の段階は、故障モード／症状マトリックスを生成することに関する。故障モード／症状マトリックスは、特定の症状が故障モードをもたらす確率を表わす値を含む。次の段階では、テーブルを検証し、検証結果を使用して、テーブルを修正することができる。これは、障害とそれらに関連付けられた症状とのリストを提供する、使われているデータ（in-service data）又はテスト装備に対してテーブルを比較することに関し得る。診断ツールにその症状を加えた場合に、診断ツールが正しく障害を識別するかをチェックするために、(例えば、米国マサチューセッツ州ナティック(Natick, MA， USA)のマスワークス（Mathworks）のマットラブ（Matlab（商標））のようなツールを使用して）ユニットテストを作成して利用してもよい。大きなモデルを処理する場合に、設定された数の障害を選択してテーブルを検証してもよいが、より小さなモデルを用いて、全ての障害をテストしてもよい。]
[0019] 上述のように、モデル作成プロセスにおける初期段階は、システムの記述を作成することに関する。図１は、システムを概略的に示しており、システムは階層200に分解されている。２つの同じポンプトレイサブシステムを具備する１つのポンプトレイシステムが例示されている。この例示的なシステムの個々のコンポーネントの全てを一般化するために、コンポーネントの３つの異なるタイプ、即ち、ポンプタイプ202Aと、センサタイプ202Bと、バルブタイプ202Cとが使用され得る。例示的なポンプトレイサブシステム中には、ポンプタイプのデバイスの２つのインスタンス204A、204Bと、センサの１つのインスタンス204Cと、バルブの１つのインスタンス204Dとがある。これらのコンポーネントを具備するサブシステム自体は、全体的なサブシステムのタイプ206として識別することができる。サブシステムのタイプの２つのインスタンス208A、208Bは、図の下の方に示されている。従って、モデル化される任意のシステムにおいて、モデルのコンポーネント／サブシステムは、タイプのデータとインスタンスのデータとに分けることができると理解される。] 図１
[0020] 障害／症状モデルを作成するために、タイプのデータは、同じタイプの全てのコンポーネント／サブシステムに共通する故障の特徴を記載した情報を含む(例えば、タイプのデータ構造は適切なフィールドを含むことができる)か、又は関連付けることができる(例えば、実際に情報を含む個別のデータ構造が使用され得る)。更に、インスタンスのデータは、局所的な故障の影響を記載したデータを含む／関連付けることができる。インスタンスは特定の近隣要素に左右され得るので、局所的な故障の影響は、異なるインスタンスごとに異なり得る。]
[0021] ここに記載されている例では、グラフィカルユーザインターフェイスを有するソフトウェアアプリケーションを使用して、障害／症状モデルの構築を助ける。障害／症状モデルは、システムにおける症状の一定の組の中の可能性の高い原因を識別するために、診断ツールによって使用され得る。図２は、これらのタスクを行なうために構成されたコンピューティングデバイス300の模式図である。コンピュータ300は、プロセッサ302と内部メモリ304とを含む。コンピュータは、他の従来の特徴、例えば、ディスプレイと、ユーザ入力デバイス(例えば、マウス／キーボード)と、外部メモリと、ネットワーク接続とを含み得ることが分かるであろう。メモリ304は、障害／症状モデル308を表わすデータを作成するために使用されるモデル構築アプリケーション306と、そのモデルデータを使用することができる診断ツール310とを含むコードを記憶する。] 図２
[0022] ここに記載されている例において、モデル構築アプリケーション306は、マイクロソフトビジオ（商標）２００３又は２００７プロフェッショナルを含む。しかしながら、ｓｍａｒｔｄｒａｗ．ｃｏｍのスマートドロー（SmartDraw（商標））又はｋｏｆｆｉｃｅ．ｏｒｇのキビオ（Kivio（商標））のような、他の適切な図面パッケージを使用／に適応できることが分かるであろう。マイクロソフト ビジオ（商標）は、フローチャートと、ダイヤグラムと、平面図とを作成するためにしばしば使用されるベクトル図面パッケージである。大抵のベクトルグラフィックスパッケージのように、基本オブジェクトからシェイプを作成することができるが、ビジオ（商標）は、「ステンシル」と呼ばれるセットの中に、「マスタ」と呼ばれる様々な所定のシェイプを含んでいる。図面／文書と共に、多数のステンシルをロードすることができ、ユーザは、マスタから図面にドラッグアンドドロップして、「シェイプ」と呼ばれるマスタのインスタンスを追加することができる。ビジオ（商標）は、マスタとシェイプとのリンクを作成する。マスタが変更されると、シェイプが更新される。紙の概略図をスキャナで読み込んで、ビジオ（商標）の文書に対する背景として、その画像を貼り付けることができる。ユーザは、シェイプがトレースされているかのように、シェイプをその上に描くことができ、これは、紙から電子フォーマットへのデータの転送を支援することができる。従って、ビジオ（商標）は、モデル化されるシステムを形成しているコンポーネント／サブシステムを表わす模式図の作成に適したツールである。]
[0023] ユーザが所定のフィールドにデータを入力することを可能にする「マスタシェイプ編集（Edit Master Shape）」の特徴を使用することによって、任意のシェイプにシェイプデータを関連付けることができる。任意のシェイプは、マスタを構成しているシェイプを含む。更に、「定義（Define）」ボタンを使用して、フィールドを変更することも可能である。「定義」ボタンによって、データフィールドの組を作成して、シェイプにドロップすることができ、多数のシェイプが同じシェイプデータフィールドを有することができる。この「シェイプデータ」機能は、モデル化されるコンポーネント／サブシステムに、故障の特徴のデータを関連付けるために考えられた。しかしながら、本発明者が、ビジオ（商標）を使用して、システムのサブシステムの作成を試しているときに、このアプリケーションの限界を発見した。サブシステムをグループ化して、マスタ(即ち、文書からステンシルにドラッグされたグループ)を作成するときに、サブシステム内のシェイプから元のマスタへのリンクは失われる。従って、ユーザは、文書内でマスタの全てのインスタンスを追跡することはできない。]
[0024] 通常は(即ち、グループ化しないならば)、マスタのバルブが変更されると、文書上のバルブの各インスタンスも更新される。例えば、ユーザが、「シェイプデータ」のダイアログボックスを使用して、バルブの特徴を変えることによって、例示的なシステム中の全てのバルブが赤で示されるように変更することができる。しかしながら、例えば、バルブのマスタの色が赤に変更されたときに、それがサブシステム内のバルブのシェイプを更新しないことが分かった。即ち、サブシステム内のバルブのシェイプは、ステンシル中のマスタのバルブに最早リンクしていない。これは、コンポーネント／サブシステムのタイプに関連付けられた障害の特徴の情報を作成／記憶するために、ビジオ（商標）のシェイプデータの使用を試みるだけで問題になることを示している。]
[0025] それらが識別したハードウェアシステムにおけるシミュレート／障害発見の技術的な目的のために設計されたツールに関する問題を考慮して、本発明者は、故障の特徴のデータをシステムのコンポーネント／サブグループに正確に関連付けることを可能にするために、ビジオの機能を拡張することにした。本発明者は、ビジオ（商標）の「アドオン」によって、これを達成する最も便利なやり方を発見したが、例えばビジュアルベーシック（商標）フォーアプリケーション（Visual Basic for Applications, VBA)を使用することによる代案が存在することは、当業者に分かるであろう。ビジオ（商標）のアプリケーションに対する拡張的なアクセスを可能にするソフトウェアツールを開発することによって、ビジオ（商標）のアドオンにより、ユーザはアプリケーションの機能を拡張することができる。アドオンは、コンポーネントオブジェクトモデル(Component Object Model, COM)をサポートする任意の言語(例えば、Ｃ＋＋、Ｃ＃、ＶＢ、又はＶＢ．ＮＥＴ)で書くことができる。１つの実施形態の場合には、Ｃ＋＋コードで書かれている。Ｃ＋＋コードは、ビジオ（商標）２００３ソフトウェア開発キットに含まれている「フローチャート」の例に含まれているコードに部分的に基づいている。ビジオ（商標）の実行時に、このコードは永続的イベントを「捕らえる（catch）」機能を含む。アドオンを実行すると、アドオンは、アクティブな文書が現在監視されているかどうかチェックして、監視されていない場合には、イベントシンクを作成して、それを文書ラッパに追加して、イベントシンクがイベントをチェックする。これは、新たなシェイプが図面にいつ追加されたかを検出するのに役立つ。従って、後述するように、コンポーネントのタイプのデータを作成／相互参照することができる。]
[0026] ビジオ（商標）の用語である「マスタ」及び「シェイプ」は、それぞれ、タイプ及びインスタンスとほぼ同等に見なすことができる。ここで、「コンポーネントのタイプ」及び「コンポーネント」という用語は、それぞれ、アドオンによって取り扱われる、コンポーネントのタイプ及びコンポーネントのインスタンス(例えば、ポンプタイプ、及びポンプ番号４のようなポンプの特定のインスタンス)を示す。例示的なアドオンにおいて、コンポーネントについて記載しているデータは、コンポーネントの名称、コンポーネントの記述、及びコンポーネントのタイプの表示を含む。しかしながら、コンポーネントに対して異なる／追加のデータを使用できることが分かるであろう。コンポーネントのタイプのデータは、タイプの名称と記述とを含む。]
[0027] 図３は、コンポーネントのデータとコンポーネントのタイプのデータとの関係性を図示している。例示的な図には、２つのコンポーネント(のインスタンス)、即ち、ポンプ１(402A)及びポンプ２(402B)がある。これらの各々は、コンポーネントのデータ404A、404Bにそれぞれ関連付けられている。更に、各コンポーネント402A、402Bは、１つのコンポーネントのタイプのデータ406に関連付けられている(その理由は、両者のコンポーネントは、同じタイプ、即ち、ポンプであるからである)。一例において、コンポーネントのタイプのデータ406は、故障モードと影響とを記載したデータを含んでいる。故障モードと影響は、そのタイプの全てのコンポーネントに共通しており、そのコンポーネントの全てのインスタンスによって共有される。コンポーネントのデータ404A及び404Bは、それぞれ、ポンプ402A及び402Bに対する局所的な影響、例えば、各ポンプの直ぐ隣のコンポーネントごとの影響のリストを含んでいる。任意の適切なデータ構造、例えば、簡単なテーブル、木、等を使用して、データを記憶及び操作できることが分かるであろう。] 図３
[0028] ここで、ビジオ（商標）とアドオンの実施形態とを使用するモデル作成の例を記載する。作成される個々のモデルに応じて、後述の動作のうちの幾つかは、異なる順序で行なわれてもよく、又はその一部を省いてもよいことが分かるであろう。第１に、モデルについての新たな文書を作成して、必要なシェイプを含む(例えば、ビジオ（商標）２００７プロフェッショナルに備えられているプロセスのフローダイヤグラムのテンプレートの中で見付けられるものに基づく)ステンシルを開くことができる。開かれたシステムの概略図の画像を、図面に貼り付けることができる。新たなコンポーネントが明確に分かるように、貼り付けられた画像の透明度を変えてもよい。図４は、ビジオ（商標）のスクリーンディスプレイの例であって、ビジオ（商標）を使用して描かれた幾つかのコンポーネント(濃い線で示されている、例えば、ポンプのシェイプ502)と共に、貼り付けられた画像(細く薄い線で示されている)を、その上に重ねて示している。] 図４
[0029] 透明な図面の上に模式図を描くと、故障モード及び影響のデータをコンポーネントに追加することができる。例えばメニューオプションを選択することによって、システムのコンポーネントを描いている途中又は描いた後の任意のときに、これを行うことができるが、一例において、アドオンが「シェイプ追加」イベントを検出して、新たなコンポーネントに対する故障データのエントリを促すことができることが分かるであろう。コンポーネントが新たなタイプである場合に、そのコンポーネントのタイプに対する故障データのエントリが促される。]
[0030] 図４の例を参照すると、ポンプのコンポーネント502のタイプに関するデータを入力するためのデータエントリボックス504が示されている。コンポーネントのタイプの名称506と、コンポーネントのタイプの記述508とを、このボックスに入力することができる。更に、そのタイプの全てのコンポーネントに共通する故障モードのリスト510と、そのタイプの全てのコンポーネントに共通する故障の影響のリスト512とが存在する。適切なボタンを使用して、これらのリスト中のエントリを追加、編集、又は削除することができる。図には、例示的な故障モードが入力されている。障害／症状モデルを完成させるために、更なるデータが追加されることが分かるであろう。例えばカンマで区切られた変数ファイル（comma separated variable file）のような、アドオンにより入力された一部のデータをエクスポートして、例えばスプレッドシートのような、別のアプリケーションを使用して、そのデータに追加することによって、これを行なうことができる。その代わりに、アドオンのデータエントリボックスを拡張して、追加の故障／影響データを入力できるようにしてもよい。例えば、コンポーネント別の故障データを入力するために、コンポーネント(タイプではなく、インスタンス)のデータエントリボックスを備えてもよい。更に、ここに詳しく記載されたコンポーネント／コンポーネントのタイプのデータに類似したやり方で、サブシステム及びサブシステムのタイプのデータを作成して操作することができるので、コンポーネントのグループを識別できることが分かるであろう。下記のテーブルは、システムに取り込むことができる故障の特徴情報の別の部分的な例を示している。] 図４
[0031] ビジオ（商標）における全てのマスタとシェイプは、シェイプのインスタンスを追跡するために使用できる一意の識別子を有する。更に、マスタは、共通のマスタを識別できるようにする一意のＩＤを有する。一意のＩＤによってインデックスを付されたコンポーネントのタイプとコンポーネントとのマップを構築することにより、データを複製せずに、データに速くアクセスすることができる。従って、アドオンによって集められたデータを(任意の適切なフォーマットで)エクスポートして、障害発見の診断アプリケーションによって直ぐに使用することができる。診断ツールの発見に基づいて、モデル化されたシステムを(自動的に)適応させる、例えば、非常バルブを開くことができる。]
[0032] 図５は、アドオンが「シェイプ追加」イベントを捕らえたときに、即ち、新たなコンポーネントが描かれたときに、アドオンによって行なわれるステップを概略的に示している。ステップ602において、描かれるシェイプのマスタが決定される。ステップ604において、そのマスタに対応するコンポーネントのタイプのデータが既に存在しているかどうかについて、質問される。否定の答えである場合に、シェイプによって表現されているコンポーネントに対するコンポーネントのタイプのデータが、例えば上述のデータエントリボックスを介して、作成される。次に、アドオンによって維持されているマップに、コンポーネントのタイプのデータが記憶される。] 図５
[0033] ステップ606において、シェイプをコンポーネントのデータにラップ／関連付けて、アドオンがそれをコンポーネントとして認識できるようにする。ステップ608において、コンポーネントからコンポーネントのタイプへのリンクを作成して、ステップ610において、この情報をアドオンのマップに記憶する。従って、(各コンポーネントと適切なタイプとの関連付けを有する)コンポーネントとコンポーネントのタイプとのリストを表わすデータを作成して、上述の診断ツールで使用するために記憶／転送することができる。アドオンにより、同じタイプのコンポーネントはデータを共有することができるので、反復的なデータの入力は回避され、これは誤り率を下げることができる。アプリケーションによって作成されたデータは、再使用のために「ライブラリ」として記憶することができる。テキストベースのモデルデータ構築技術のように、文字列を検索するのではなく、図面上の関連するシェイプを見付けることによって、データを速く便利に変更することができる。「選択の追加」の特徴により、ダイヤグラム全体を描き直すことを必要とせずに、ビジオ（商標）で描かれた既存の概略図を使用することができる。]
[0034] 200・・・階層、300・・・コンピュータ、304・・・メモリ、402A,402B・・・コンポーネント、404A,404B・・・コンポーネントのデータ、406・・・コンポーネントのタイプのデータ、502・・・ポンプコンポーネント、504・・・データエントリボックス、510・・・故障モードのリスト、512・・・故障の影響のリスト。]

权利要求:

請求項1
複数のコンポーネントを具備するシステムの故障モード影響解析を支援する方法であって、システムの、コンポーネント、又はコンポーネントのグループに関連付けられたデータを取得するステップと、前記コンポーネント又は前記グループを、コンポーネントのタイプのデータ又はグループのタイプのデータにそれぞれ関連付けるステップと、前記システムの故障モード影響解析において使用するために、前記コンポーネント／グループのデータと前記コンポーネント／グループのタイプのデータとを記憶及び／又は転送するステップと、を含み、前記コンポーネントのタイプのデータ又は前記グループのタイプのデータは、そのタイプの、全てのコンポーネント又はグループに、それぞれ共通する少なくとも１つの故障の特徴に関するデータを含む、方法。
請求項2
前記システムのコンポーネントに関連付けられたデータを取得するステップは、前記コンポーネントが前記コンポーネントのタイプのデータに既に関連付けられているかどうかを決定するために、前記システムのモデルを解析するステップ、を含み、前記コンポーネントが前記コンポーネントのタイプのデータにまだ関連付けられていない場合には、前記コンポーネントに対するコンポーネントのタイプのデータを作成して、前記コンポーネントに関連付ける、請求項１に記載の方法。
請求項3
前記モデルを解析するステップは、前記モデル中の前記コンポーネントの図形表現のシェイプを検出するステップと、前記コンポーネントに関連付けられる前記コンポーネントのタイプのデータを決定するために、前記シェイプが基づくマスタ又はテンプレートを決定するステップと、を含む、請求項２に記載の方法。
請求項4
前記故障の特徴のデータは、前記故障のタイプ／名称／モード、前記システム及び／又は他のコンポーネントに対する前記故障の影響、前記故障の症状、前記故障の症状が前記故障の発生につながる確率を表わす値、前記故障が発生する先験的確率、症状が１つの(又は１つのみの)前記故障をもたらす条件付き確率、症状がモデル化された故障をもたらさない確率、から成る１つの組から選択される、請求項１乃至３の何れか１項に記載の方法。
請求項5
前記コンポーネント／グループのタイプのデータは、前記コンポーネント／グループのデータから独立して記憶される、請求項１乃至４の何れか１項に記載の方法。
請求項6
前記コンポーネント／グループのタイプのデータは、特定のコンポーネント／グループの故障の、他のコンポーネント及び／又は他のグループ及び／又は前記システムに対する影響を記載したデータのような、前記特定のコンポーネント／グループの故障の特徴に関するデータを含む又は関連付けられる、請求項１乃至５の何れか１項に記載の方法。
請求項7
前記モデル中の前記コンポーネントの各々は、一意の識別子を割り当てられ、前記コンポーネントのタイプの各々は、一意の識別子を割り当てられ、前記コンポーネントのデータと前記コンポーネントのタイプのデータとを記憶及び／又は転送するステップは、前記コンポーネントの一意の識別子と、前記コンポーネントに関連付けられた前記コンポーネントのタイプの一意の識別子との間のリファレンスと共に、前記コンポーネントのデータを記憶／転送するステップを含む、請求項１乃至６の何れか１項に記載の方法。
請求項8
前記システムの前記モデルの図形部分は、マイクロソフトビジオ（商標）を使用して作成され、前記コンポーネントを表現するシェイプを検出するステップは、ビジオ（商標）における「シェイプ追加」イベントを検出するように構成されたアドオンによって実施される、請求項１乃至７の何れか１項に記載の方法。
請求項9
プログラムコードがロードされたときに、複数のコンポーネントを具備するシステムの故障モード影響解析を支援する方法を、コンピュータに実行させる、コンピュータプログラムコード手段を有する、コンピュータ読み出し可能媒体を具備する、コンピュータプログラム製品であって、前記方法は、システムの、コンポーネント、又はコンポーネントのグループに関連付けられたデータを取得するステップと、前記コンポーネント又は前記グループを、コンポーネントのタイプのデータ又はグループのタイプのデータにそれぞれ関連付けるステップと、前記システムの故障モード影響解析において使用するために、前記コンポーネント／グループのデータと前記コンポーネント／グループのタイプのデータとを記憶及び／又は転送するステップと、を含み、前記コンポーネントのタイプのデータ又は前記グループのタイプのデータは、そのタイプの、全てのコンポーネント又はグループに、それぞれ共通する少なくとも１つの故障の特徴に関するデータを含む、コンピュータプログラム製品。
請求項10
複数のコンポーネントを具備するシステムの故障モード影響解析を支援するように構成された装置であって、システムのコンポーネントに関連付けられたデータを取得するように構成されたデバイスと、前記コンポーネントをコンポーネントのタイプのデータに関連付けるように構成されたデバイスと、前記システムの故障モード影響解析において使用するために、前記コンポーネントと前記コンポーネントのタイプのデータとを記憶及び／又は転送するデバイスと、を含み、前記コンポーネントのタイプのデータは、そのコンポーネントのタイプの全てのコンポーネントに共通する少なくとも１つの故障の特徴に関するデータを含む、装置。